Tools for constructing requirements specifications: The SCR toolset at the age of ten

The need for unambiguous, easy-to-understand notations for specifying and analyzing the requirements of systems is widely recognized. Tables have been demonstrated to offer a precise, relatively compact notation for specifying system requirements in a wide range of applications, including avionics systems, systems for controlling nuclear power plants, and telephone networks (see, for example, [32, 47, 13, 53, 34]). Developers have also found tabular notations easier to write and to understand than alternative notations, such as Z and Petri nets. In addition, tables can be assigned a precise mathematical semantics and thus can be analyzed either manually or mechanically to expose defects in requirements specifications. Finally, tabular notations have been demonstrated to scale to practical systems. In 1978, the requirements document for the flight program of the A-7 aircraft [32, 33] introduced a special tabular notation for writing specifications. Part of the SCR (Software Cost Reduction) requirements method, this notation was designed to document the requirements of real-time, embedded systems concisely and unambiguously. During the 1980s and 1990s, SCR tables were used by several organizations in industry and government, e.g. Grumman [47], Bell Laboratories [34], Ontario Hydro [53], the Naval Research Laboratory [31], and Lockheed [13], to document the requirements of many practical systems, including a submarine communications system [31], the shutdown system for the Darlington nuclear power plant [53], and the flight program for Lockheed’s C-130J aircraft [13]. The Lockheed specification contains over 1000 tables and the corresponding flight program over 250K lines of Ada [59] – solid evidence that the tabular notation scales. Analysis of these tables for errors was largely manual. A serious problem with manual inspections is their high cost – the inspection of tables in the certification of the Darlington shutdown system, for example, cost millions of dollars. Moreover, manual inspections often miss certain classes of specification errors software tools detect. In a study conducted in 1996, a mechanized analysis of the A-7 requirements specification, which had previously undergone manual inspections by two independent review teams, exposed 17